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Abstract. Experienced systems engineers are adept at more than implementing systems 
engineering processes: they utilize systems thinking to solve complex engineering problems. 
Within the space industry demographics and economic pressures are reducing the number of 
experienced systems engineers that will be available in the future. Collaborative systems thinking 
within systems engineering teams is proposed as a way to integrate systems engineers of various 
experience levels to handle complex systems engineering challenges. This paper uses the 
GOES-R Program Systems Engineering team to illustrate the enablers and barriers to team level 
systems thinking and to identify ways in which performance could be improved. Ways NASA 
could expand its engineering training to promote team-level systems thinking are proposed. 

Introduction: What is Collaborative Systems Thinking? 

Systems Thinking: Broadly defined, systems thinking is a way of thinking about the whole: a 
system and its context. While many definitions exist for systems thinking, the common themes 
across these definitions are complexity, interrelationships (interfaces), context, emergence, and 
holism. Definitions specific to engineering focus on the use of tools and experience to consider the 
technical and social component and interactions of a system (Davidz 2006) and associated systems 
thinking with problem solving and brainstorming activities (Jansma and Jones 2006). 

Systems thinking is a skill leveraged to avoid potential future problems. Systems thinking skills 
include understanding dynamic system behavior, identifying feedback processes, finding and 
explaining patterns of system behavior, and identifying ways in which to influence that behavior 
(Richmond 1993, Sweeney and Sterman 2000). Such skills are useful in understanding the 
limitations of systems models, interpreting and influencing non-linear processes, and recognizing 
time delays between systems inputs and outputs (Sweeney and Sterman 2000). 

Within engineering, systems thinking development is enabled by experience, individual 
characteristics (e.g. curiosity and a tolerance for uncertainty), and a work environment that 


supports the development of systems skills (Davidz 2006). For a more detailed discussion of 
systems thinking definitions and development, see (Davidz 2006) and (Lamb and Rhodes 2008). 

Defining Collaborative Systems Thinking: Inputs from literature and a set of interviews (see 
Lamb and Rhodes 2009) were used to form a definition of collaborative systems thinking. In 
addition to the common system thinking definition themes, literature on team thinking and 
memory emphasized the role of team interactions, or transactions, in forming both a shared 
understanding of the systems and pointers to specialized knowledge and experience within a team 
(Salas and Fiore 2004, Wegner 1986). Also found in the literature was demonstration of the 
importance of diversity in thinking styles (e.g. divergent, convergent) as important for the design 
process (Stempfle and Badke-Schaub 2002). Further literature highlighted the importance of 
communicating technical information using multiple communication media (e.g. sketches, 
questions, models) (Dym et al 2005). 

Interviews with senior systems engineers and program managers within the aerospace industry 
revealed phrases such as ‘holistic approach,’ ‘understand the problem, ‘keeping a systems view’, 
and ‘teasing out interconnectedness.’ These interviews also introduced the concepts of producing 
a final product, managing interactions among multiple functions, using multiple and 
high-bandwidth forms of communication (e.g. face-to-face), the importance of a creative and 
supportive environment, the use of standard design process to manage design knowledge, being 
aware of other teams’ members, and the need for leadership recognition and support of systems 
thinking. 

By integrating these inputs, the following definition of collaborative systems thinking was 
derived: 

Collaborative systems thinking is “an emergent behavior of teams resulting from the 
in teractions of team members and utilizing a variety of thinking styles, design processes, 
tools, and communication media to consider the system, its components, 
interrelationships, context and dynamics toward executing systems design. ” (Lamb and 
Rhodes 2008) 

This definition captures the primary difference between individual and team systems thinking: the 
concept of team thinking, or the group processing of information including recall and 
interpretation. Given the importance of experience in developing systems thinking and the 
reduced opportunities to gain such experience, teams offer an opportunity to pool systems 
experience into one working unit. Focusing on the team level also emphasizes creating a 
supportive environment for systems thinking expression and development. Such an environment 
facilitates the exchange of knowledge from experienced engineers to younger engineers in the 
forms of hands-on mentoring, parables, and shared references. In such a context, not only will 
younger engineers be exposed to systems thinking, they will be learning from a wide base of 
experience to which they might otherwise not have access. 

The Challenge: An aging workforce threatens 
systems thinking resources 

If experience is critical for systems thinking development, it is logical that experienced engineers 
are more proficient systems thinkers. Individuals with 30+ years of program experiene comprise 
40% of the aerospace workforce. Many of these individuals are currently eligible for retirement: 



65% of these most experienced workers will be eligible for retirement by 2014. At the same time 
lesser experienced engineers are finding fewer opportunities to gain the experiential learning 
critical to systems thinking development. 

Engineering Demographics: 

Twenty-five percent of the 
aerospace industry will be 
eligible for retirement by 
2011 according to (Black et al 
2006). This 25% represents 
the engineers with the 
greatest depth and breadth of 
program experience: the 

individuals who have been 
most enabled to develop 
systems thinking. Figure 1 
shows that the Goddard Space 
Flight Center (GSFC) science 
and engineering workforce is 
slightly older than the overall 
Aerospace workforce, and 

much older than the entire US „ Figure 1 :GSFC, Aerospace cane US Workforce 
workforce in tenns of Demographics adapted from NASA Workforce Information 

retirement' eligibility, 17% of Cubes and < Black et al 2006 > 

the GSFC science and engineering workforce is currently eligible for retirement and 30% of the 

current workforce will be eligible for retirement within the next five years. 



Program Opportunities: An aging workforce is not itself necessarily a cause for concern. 
However, there are fewer new large programs and these programs have longer lifecycles than their 
predecessor programs. Therefore, younger engineers will not have the same quantity of career 
systems experiences as engineers more advanced in their careers. Because systems thinking 
development is linked to systems experience (Davidz 2006), fewer programs mean fewer 
opportunities to develop systems thinking skills. Engineers who entered the industry in the 1960s 
had the opportunity to work on six different manned space flight programs over a 40 year career. 
An engineer entering the industry in the mid-1980s has had experience with only one or two 
manned space flight programs. As NASA ramps up the Constellation program, many of the 
younger engineers on the program will have no manned space flight program development 
experience. Without opportunities to develop systems thinking, these engineers are more likely to 
relearn lessons of the past by repeating old mistakes on new programs. 

Good Systems Engineering Processes Can Help: The goal of processes within systems 
engineering is to address problems across the system’s lifecycle in a systematic way. One of the 
objectives of engineering process standardization is the accurate prediction of cost, schedule, and 
performance. Engineers are the most variable component of the design process (Martin and 
Davidz 2007). Introducing standard ways of executing tasks helps to reduce this variability and 
facilitate scheduling and cost estimating, and enable the overall effectiveness of the engineering 
effort. Standards support engineering excellence by saving engineers from ‘reinventing the wheel’ 
and preserving efforts for true innovation (Gill and Vaughan 2006). Standard processes capture 
good systems engineering practices and help to ensure interfaces and requirements are properly 


managed. Standard processes and best practices are based on lessons of the past (So and Andary 
2007). 

But, Processes are Not Enough: Even the best process, though, cannot take a bad program and 
make it good. Rather, good processes when appropriately followed keep a good program on track. 
Leadership and the “art” of systems engineering are the additional needed components for success 
(Ryschkewitsch 2008). While systems engineering deals with requirements and interfaces, 
creating these are not the end goal. Finding the right design is the end goal of systems engineering 
(Griffin 2007). This pursuit is aided by process, but also requires the systems engineer to act as the 
link between the art and science of engineering; bridging the gap between design and analysis. 
Whereas analysis is conducive to rules and processes, the art of system engineering is learned 
through experience and incorporates systems thinking, the ability to know when and where to 
probe a design. 

Addressing the Challenge: Collaborative Systems Thinking 

Through 10 full and 17 abbreviated case studies, a set of collaborative systems thinking team traits 
were identified. The methodology used and the results are discussed in more detail in (Lamb and 
Rhodes 2009). Below is a brief discussion of identified collaborative systems thinking team traits. 

Generalized Traits of Collaborative Systems Thinking Teams: Three generalized traits of 
collaborative systems thinking (CST) teams are that these teams have comparatively more 
program experience, inclusive cultures and consistent team structures. In the discussion below, 
collaborative systems thinking ability is a triangulated measure based on inputs from team 
members and third-party assessments of team performance. 

Team experience is an indicator of CST. Both years of experience and number of past similar 
program experiences were correlated to team CST. Because individuals on teams represented a 
wide range of experience (4-40 years and 0-15 past programs on some teams), the mode of each 
team was used as most representative of the average team member’s experience. By this metric, 
years of experience and team collaborative systems thinking are correlated with a coefficient of 
0.63. The number of past programs worked is a better predictor of CST, with a correlation 
coefficient of 0.86. Because systems skills are based on an understanding or appreciation of the 
entire system, it is logical that the number of systems worked is a better indicator of systems 
thinking. This observation reinforces the value of internal research and development (1R&D) 
programs that provide opportunities for early career hires to participate in multiple programs and 
program lifecycle phases, thus providing the necessary systems experience to foster strong CST 
teams. 

A team’s culture is also an important indicator of its CST ability. CST teams have cultures of 
inclusion; these are teams in which individuals have a sense of participation. One measure of this 
participation is decision making. Team members were asked to rank the relative frequency of 
individual decisions versus consensus decisions. The rate of team, or consensus, decision making 
has a strong correlation (C=0.70) with team reported collaborative systems thinking ability. 
Another indication of CST team culture showed up in team communication preferences. CST 
teams were more likely to describe their teams as having open communication based on 
face-to-face communication. These teams describe themselves as more creative and were more 
likely to use sketches, prototypes, and models to communicate technical ideas. 

CST Team Structure: One consistent difference between teams with high and low ratings of 



collaborative systems thinking was team structure. The structure observed consists of three tiers 
of team membership: systems leadership, an intermediary, or ‘middle’ tier of developing systems 
professionals with functional backgrounds, and functional experts. This structure, observed 
through organizational charts or discerned through conversation with team members, was 
observed in each of the six full case studies with high rankings for collaborative systems thinking. 
One or more tier was absent in those case studies with lower ratings of CST. The pattern was also 
reinforced through the abbreviated case studies, in which individuals described the structural traits 
of high and low CST teams on which they had participated. 

The systems thinking leadership of a team is composed of one or more individuals, all strong 
individual systems thinkers, who balance both the technical and social interactions of the team. 
These individuals guide their team, adjusting their interaction style to best serve their purpose and 
audience. They excel at communicating at multiple levels of abstractions and multiple levels of 
system detail. These traits align with those of the ‘highly regarded’ systems engineers 
characterized in (Derro 2008). These traits, developed from a study of effective systems engineers 
at NASA, include the ability to influence others, strong communication skills, engaging in 
mentoring, critical thinking, risk management, and the ability to lead others to new insight using 
analogy and insightful questioning. 

The middle tier of developing systems professionals consists of individuals with functional 
responsibilities (e.g. subsystems leads or representatives of different functions) who interact 
closely and have an appreciation for systems issues. These individuals act as an interface between 
the functional experts and the systems leadership. The middle tier excels at presenting detailed 
technical information, tailoring the presentation to their audience and facilitating decision making. 
By nature of their role within the team, these individuals are well poised to develop strong systems 
skills. 

The functional experts bring specialized technical knowledge to the team. These individuals are 
less involved in the day-to-day interactions and decision making of any single team, as they often 
contribute to several teams simultaneously. As such, the functional experts are less aware of 
systems issues and the greater systems picture. 

A team lacking any one of these tiers suffers from a lack of leadership and/or a failure to process 
and share the information necessary to support decision making. 

CASE STUDY: GOES-R 

What is GOES-R? The National Oceanic and Atmospheric Administration (NOAA) operates a 
system of Geostationary Operational Enviromnental Satellites (GOES) to provide continuous 
weather imagery and monitoring of meteorological and space environment data to protect life and 
property across the United States. One of NOAA’s principal missions is to provide forecasts and 
warnings for the United States, its territories, adjacent waters and ocean area for the protection of 
life and property and enhancement of the national economy. This mission requires the capability 
to acquire, process, and disseminate environmental data on an extensive spatial range (global, 
regional and local) on a variety of time scales. Two GOES satellites remain operational at all times 
providing coverage for the eastern United States and most of the Atlantic Ocean and the western 
United States and Pacific Ocean basin. GOES satellites provide critical atmospheric, oceanic, 
climatic and space weather products supporting weather forecasting and warnings, climatologic 
analysis and prediction, ecosystems management, and safe and efficient public and private 


transportation. The GOES satellites also provide a platform for solar and space environmental 
observations. 


The GOES program currently consists of three series of satellites — identified by letters during 
development, and numerically post-launch. The GOES-I/M series (8-12) is the current operational 
series. Transition to the GOES-N/P series has commenced with the successful launch of GOES- 13 
in 2006. The GOES-I/M and -N/P series share the same generation primary instrument payload. 
The GOES-R series is a $7 billion system of satellites, sensors and data processing and distribution, 
which represents a generational change in both spacecraft and instrument capability, with initial 
launch capability in 2015. It will provide the first major improvement in instrument technology 
since GOES-I was launched in 1994. The GOES-R series will introduce other new technologies in 
both the Space and Ground Segments. These advances will improve the nation’s ability to monitor 
and forecast weather and environmental phenomena with a significant increase in the number of 
products. 
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Figure 2: Diagram of GOES-R Program Structure 


GOES-R Program 

Structure. GOES-R is a 
collaborative development 
and acquisition effort 
between NOAA and the 
National Aeronautics and 
Space Administration 
(NASA). Program 

activities occur at the 
co-located Program and 
Project Offices at Goddard 
Space Flight Center. The 
GOES-R program 

acquisition and 

management strategy was 
restructured at the end of 
the Formulation Phase from 
a single-system prime 
NOAA contract acquisition 
to an inter-agency 


dual-contract acquisition for the Acquisition and Operations Phase of the Program. Under a 
dual-contract acquisition strategy, NASA is procuring the Space Segment and NOAA is procuring 
the Ground Segment. A Program Systems Engineering Team was created to ensure the overall 
system engineering and integration is accomplished. This group is responsible for end-to-end 
systems requirements definition, design, integration, planning, coordination, and adjudication of 
the space and ground segments. One of the group’s challenges is to tailor procedures to apply to 
the GOES-R program to meet the unique demands of this joint inter-agency acquisition — 
safeguarding NOAA’s oversight of the GOES-R program while also safeguarding NASA’s 
effective exercise of its expertise over the Flight Project. Another challenge is to identify and 
remediate inconsistencies between the designs, schedules and test plans of the two projects as early 
as possible in the program when they are less costly to fix. The Program Systems Engineering 


Team (PSE) is central to integrating the strengths of two agencies to create the best system 
possible. 

GOES-R Program Systems Engineering (PSE). The PSE consists of approximately 20 systems 
engineers with a wide range of backgrounds - software, mechanical and electrical engineering as 
well as meteorology and project management. Rather than focusing on instrument or satellite 
subsystems, individuals focus on general programmatic themes -system design, integration, 
testing, configuration control, requirements tracking and flow, image navigation and registration, 
instrument processing algorithms, and science product algorithms. There is considerable overlap 
among these themes, requiring team members to work collaboratively. The team lead is a NASA 
systems engineer and the deputy is a NOAA systems engineer. The rest of the team is a collection 
of NASA and NOAA civil servants and contractors from several companies on several support 
contracts. Team members are chosen primarily by the expertise they bring to the group, rather 
than based on their corporate affiliation. The PSE team chose to participate in this study in order to 
gain insights into its strengths and weakness in the area of CST with the goal of improving. High 
CST ability is crucial to the success of this team and due to its critical program integration role, to 
the success of the entire $7 billion program. A discussion of how well this team embodies the three 
traits of collaborative systems thinking follows. 

The first trait is program experience. The GOES-R PSE team members have comparatively fewer 
past program experiences as compared to other teams in the study. On average, NASA and NOAA 
have large programs with long lifecycles - the GOES program has been in existence for decades, 
so this finding is expected. Team members have more experience in the current program or a 
small number of other programs, but lack the perspective and breadth of knowledge gained from 
supporting multiple programs. 

The second trait is an inclusive culture. PSE’s survey results had the most positive responses to 
the question about trusting each others’ abilities to meet deadlines and about average responses to 
the question about respecting other team members’ technical abilities. The answers suggest that 
trust and respect are well in place. However, PSE is a team composed of individuals from multiple 
cultures. This is a strength due to the different skill sets that are brought together into this team, but 
can make it harder for this team to fonn a consensus around values and goals. This showed up in 
the responses on decision making that were evenly distributed between ‘consensus’ and 
‘individual’ decision making. On the survey question “Does this team have a clear goal” this 
team’s score was significantly lower than other teams in the survey. People agreed on why the 
team existed, but not what the team is doing. This is understandable given that most team 
members are new to the team. Most were project system engineers in the past and are grappling 
with the differences between project and program systems engineering. A similar pattern is 
observed for the question “Does this team engage in critical discussion of new ideas.” This shows 
that procedural issues like how decisions are made are not uniformly perceived. The PSE team is 
the ‘newest’ of the teams in the study. Most members (10/19 surveyed) have been with PSE for a 
year or less. The weaknesses identified in the survey are not surprising given the relative newness 
of the team, and are certainly correctable with time. The multiple cultures aspect is and always 
will be a challenge: PSE has representatives of three organizations (plus contractors). There’s no 
consistent incentive for everyone on the team (especially from a contractual standpoint — for the 
contractors). But this model increasingly reflects reality — especially with the prevalence of 
engineers retiring and returning as contract workers. 


As with most of the teams involved in the case studies, a portion of the PSE team is geographically 
separated from the main body of the team and relies heavily on teleconferencing and email. 

These individuals have more difficulties engaging in discussion and feeling a part of the 
team. Collaboration across distributed situations is slowed by phones that only allow one side to 
talk at a time. It’s these really small points that can interrupt the cohesiveness of a team. For PSE, 
communicating in less than optimal conditions is an ongoing challenge. When a conversation is 
really critical the geographically dispersed team members are invited to fly down to participate 
with the team directly. 

The third trait is the three tier structure described above. Considering the PSE as a team, you have 
the dual NASA/NOAA leadership and middle tier (remainder of PSE). The third tier is composed 
of the functional experts in the Ground Segment Project and Flight Project teams, who are actually 
not a part of the PSE team. The interviews suggested this is an ‘us’ and ‘them’ type situation where 
those contributing the detailed information come from the ground and flight systems groups 
having team cultures distinct from PSE and different from each other (ground more aligned with 
NOAA, flight more aligned with NASA). 

Key Challenges of the Middle Tier. In this case study, there are several challenges facing the 
Middle Tier. The first is to make up for the lack of breadth of program experience that is the reality 
for most of the team. There are several ways to do this that are in fact already being done: using 
the senior systems engineer who has that experience as a mentor and consultant, providing 
resources (books, online databases, other engineers at Goddard) so that the engineers get the data 
they lack, and to allow more time for tasks so that this data gathering process can happen. Training 
and rotation programs are also a logical solution to this challenge. 

The PSE’s next challenge is developing a common understanding, or big picture, of the GOES-R 
program. Members of PSE must understand the political drivers, the goals, the stakeholders, the 
various system components, and the history for the GOES program. Comparisons to the previous 
GOES Programs can lead to erroneous conclusions because the instruments for GOES-R have 
improvements over the previous instruments, deliver different data products, and require different 
operational processes. Comparison to previous NASA missions can lead to erroneous conclusions 
because NOAA stakeholder interests are not necessarily represented by past NASA missions. The 
GOES-R goal is to blend NASA innovation in a framework of NOAA continuity. 

Developing a unified culture within the PSE is the next challenge. The whole team must 
understand the decision making process, other team processes and the team deliverables. 
Semantics can be a barrier to this effort. A 2007 study of barrier and enablers to systems thinking 
at GSFC, showed that even within the GSFC community, there were diverse definitions for 
systems thinking. The divergence in definitions is linked to confusion over how leadership 
expected systems thinking to be demonstrated in the workplace. Other challenges seen to 
developing systems thinking include intangibles such as organizational culture and individual 
attitudes. 

The final challenge is to get members of PSE’s middle tier and the discipline engineers better 
integrated. The key here is for all to recognize that they share a common goal - the success of the 



mission. It is also important for engineers on both sides to value the contributions of the other side 
to this success. This can be fostered with more face to face contact, and joint participation in 
engineering activities. Comments and data from other case studies suggest that the functional 
experts should be held tightest during detailed design when their inputs are required frequently for 
system-level issues. The goal needs to be to get people interacting more like one big team at the 
technical level. 

In summary, the PSE team’s responses to a survey and interview support illuminate barriers 
unique to team-level systems thinking development. 

■ Barriers to team-level systems thinking included the existence of several subcultures within 
PSE (NOAA is more operational, NASA is more engineering, contractors are specialists). 
These differences showed up in differing perceptions about team decision making — which 
is split along organizational lines. 

■ The team operates in a distributed environment. Team interactions are inhibited by 
collaboration technology (e.g. conference calls). The medium for interaction limits the 
quality of conversation in which the team engages. This and other barriers to distributed 
collaboration are discussed in (Utter 2007). 

■ Reinforcing the confusion expressed by junior systems engineers in the 2007 study, the 
group relies on informal communication and coordination. While informal communication 
(e.g. water cooler conversations) has proven consistently important across companies and 
case studies, this results in some confusion about process and documentation flow within 
the middle tier. Such confusion is a particular problem within PSE because of the 
integration of NOAA and NASA systems engineering process. 

Responding to the Challenge 

What is Goddard doing to address the middle tier? NASA and Goddard systems engineering 
organizations are aware of the challenges faced by engineers in the middle tier and have taken 
steps to address them. 

Several NASA Centers have hands-on systems engineering development programs including: 
Glenn Research Center (GRC), GSFC, Jet Propulsion Lab (JPL), and Ames Research Center 
(ARC). In addition to these Center programs, the NASA Office of Chief Engineer in 2008 has 
been given the responsibility for implementing an effective systems engineering program and 
strategy across NASA. The program Systems Engineering Leadership Development Program 
(SELDP) is being developed to identify and develop the next set of “highly regarded” systems 
engineers within NASA. The SELDP program leverages existing systems engineering training 
programs within the centers such as Systems Engineering Education Development (SEED) at 
GSFC and Space Mission Excellence Program (SMEP) at the GRC. It also leverages existing 
NASA Academy of Program/Project & Engineering Leadership (APPEL) programs and courses 
for leadership training and workshops. 

At Goddard, four fundamental elements critical to developing the middle tier have been identified: 
mentoring by Systems Leaders, on the job training including rotational assignments, a curriculum 
of technical courses, and systems leadership training. The Goddard SEED Program is designed to 
develop the middle tier systems engineers into fully qualified systems engineers over a two to 
three-year period. (SEED 2006). Assignments and classes are selected to broaden the participant’s 


experience across several disciplines, subsystems, and phases of the mission life cycle. The SEED 
Program maintains at least six participants at any given time with at least three new candidates per 
year. Since SEED was created in 2002, nine engineers have graduated from the program and four 
engineers are in the current class. A new class is scheduled to be formed at the end of this year. 

Both the SELDP and the SEED Programs recently adapted a selection process that ensures the 
selection of the high potential participants. Participant selection does not only focus on identifying 
individuals who have proven technical/discipline capability, but also those who have 
demonstrated key systems engineering leadership capabilities and behaviors. Leadership elements 
include the ability to use critical and systems thinking and judgment, and the ability to make 
effective decisions for large, complex system and out-of-the-box thinking. Nominees who were 
highly ranked were interviewed to detennine if they exhibited the systems engineering leadership 
behaviors and aptitudes necessary to become an expert in the field. Systems engineering 
leadership behaviors have been identified in studies conducted at Goddard and JPL (Jansma and 
Jones 2006). Currently additional expert systems engineers at other Centers have been interviewed 
to validate these behaviors and aptitudes. 

Future Work and Conclusions 

What programs or changes could Goddard initiate? The following four areas are candidates 
for enhancing existing education courses: 

1. Educate engineers to think more deeply about systems in their context or environment. 
This should include improving the ability to understand system boundaries, and how these may 
shift over time. Engineers need to be educated to understand how systems react to 
intemal/external impacts. This includes developing knowledge of constructs for impact 
analysis and methods decision making. It should include a common “big picture” 
understanding of the system. 

2. Develop the ‘situational leadership’ abilities of engineers in regard to how to make 
decisions at multiple levels - component, system, system of systems (Rhodes et al, 2008). 
This includes an improved understanding of the decisional trade off process for local versus 
global system value delivery. This should include considering the frame of reference of the 
engineers in various organizations and in the different tiers, and developing the understanding 
that people make decisions based on individual perceptions. 

3. Provide more education and experiential learning opportunities in regard to ‘systems in 
time’. This includes how to think about systems and system interactions within and across life 
cycle phases. Also important is the ability to anticipate future scenarios, and how system 
decisions in present time may enable flexibility for the future. 

4. Recognizing the benefits of Collaborative Systems Thinking, develop training for entire 
teams, contractors and civil servants - teams such as the GOES-R PSE team. This could be 
one of the three suggestions above, or a different topic, so long as the whole team is 
participating together. 

One initiative that may benefit the middle tier systems engineers is to establish “focus groups” 
within the Engineering Directorate. These are small groups of 4 - 7 systems engineers working on 
areas with a common theme. For example, we can create a focus group for the Earth Science 
ground system engineering and a focus group for spacecraft systems engineering, etc. The 



primary purpose of these focus groups is to improve the systems engineering capabilities through 
knowledge sharing and problem solving among the group members. Additionally, they provide a 
measurement and feedback on how well the systems engineering processes were being applied on 
the various projects. They are non-confrontational assessments of the issues, successes and the 
challenges that were being faced each day by the systems engineers in the field. It may also be an 
excellent way to monitor the inner workings of the systems engineering processes without a formal 
assessment. People tend to be nervous about formal surveys and assessments and they will often 
hold back in formation or exaggerate perfonnance under the scrutiny of such formality. On the 
other hand focus groups are less formal and less confrontational and engineers are more willing to 
open up on what the real issues are. 

Goddard will continue to provide various opportunities to qualified engineers so that they can gain 
hands on systems engineering developmental experience that will broaden and improve their 
discipline knowledge, skills and abilities to lead complex projects such as GOES-R. 

References 

Black, D., Hastings, D. and the Committee on Meeting the Workforce Needs for the National 
Vision for Space Exploration. Issues Affecting the Future of the U.S. Space Science and 
Engineering Workforce: Interim report. 2006. 

Davidz, Heidi. Enabling Systems Thinking to Accelerate the Development of Senior Systems 
Engineers. PhD thesis, Massachusetts Institute of Technology, Cambridge, Massachusetts, 
2006. 

Derro, M.E., “NASA Systems Engineering Behavior Study,” http:// www.nasa . 

Gov/pdf/291039main_NASA_SE_Behavior_Study_Final_l 1 12208.pdf Accessed Nov. 2008. 
Gill. P. and Vaughan, W.. Engineering Excellence and the Role of Technical Standards. In Proc. 

44th AIAA Aerospace Sciences Meeting, Reno, NV, January 2006. 

Griffin, M. System Engineering and the “Two Cultures" of Engineering. Purdue University 
Boeing Lecture, March 2007. 

Jansma, P. and Jones, R., “Advancing the Practice of Systems Engineering at JPL”, IEEE 
Aerospace 2006, Big Sky, MT, March 2006. 

Lamb, C.T. and Rhodes, D.H. “Systems thinking as an Emergent Team Property: Ongoing 
research into enablers and barriers to team-level systems thinking,” IEEE International 
Systems Conference, New York, 2008. 

Martin, J. and Davidz, H. Systems Engineering Case Study Development. In Proc. 5th CSER 
Conference on Systems Engineering Research, Hoboken, NJ, 2007. 

Rhodes, D.H., Lamb, C.T. and Nightingale, D.J., "Empirical Research on Systems Thinking and 
Practice in the Engineering Enterprise," 2nd Annual IEEE Systems Conference, Montreal, 
Canada, April 2008 

Richmond, R., “Systems Thinking: Critical thinking skills for the 1990s and beyond”, System 
Dynamics Review, Vol. 9, No. 2, pp 1 13-133, 1993. 

Ryschkewitsch, Michael, “Systems Engineering: What you need to know but didn’t know you 
needed to know” Goddard Space Flight Center Systems Engineering Colloquium, September 
8, 2008, online at http://ses.gsfc.nasa.gov/ses data 2008/080908 Ryschkewitsch.pdf . 

SEED Team, “Goddard's SEED Program: Growing Systems Engineers”. NASA’s ASK 
Magazine, Issue 24, 2006, online at http://appel.nasa.gov/ask/issues/24/24s seed.php . 

So, M., Andary, J., and Caldwell, M. “Organizational Strategies for Systems Engineering 


Capability Improvement” INCOSE Conference 2007. 

Sweeney, L. and Sterman, J. “Bathtub Dynamics: Initial results of a systems thinking inventory”, 
System Dynamics Review, Vol. 16, No. 4, pp 249-294, 2000. 

Utter, D. Performing Successful Collaborative, Distributed Systems Engineering, Masters thesis, 
Massachusetts Institute of Technology, Cambridge, Massachusetts, 2007. 

Wegner, D. “Transactive Memory: A contemporary analysis of the group mind” Theories of 
Group Behavior. Springer- Verlag. New York. 1986. pp 185-205. 

Workforce Information Cubes for NASA, http://wicn.nssc.nasa.gov Accessed Oct 2008. 

BIOGRAPHIES 

Barbara Pfarr is currently the Program Systems Engineer for the Geostationary Operational 
Environmental Satellites (GOES) R Program. Previously, she was an Associate Chief of the 
Information Systems Division of the Goddard Space Flight Center, head of the Earth Science 
Missions Branch, which provided end-to-end systems engineering for NASA programs, missions 
and projects, and head of the Real-Time Software Engineering Branch, which developed 
Command and Control systems and simulators. She served as the Program Chair for the AAS 
Goddard Memorial Symposium in March 2005. She chaired the INCOSE Systems Engineering 
Management Working Group during 2003. She received a B.A. in Mathematics and Astronomy 
from Smith College, a M.S. in Computer Science (concentration: Artificial Intelligence) from 
Johns Hopkins, and a M.S. in Computer Science (concentration: Graphics) from George 
Washington University. 

Maria M. So is the Deputy Director for Safety and Mission Assurance at NASA’s Goddard Space 
Flight Center. Ms. So joined NASA in 1992 as the Hubble Space Telescope Project Operations 
Data Manager and led several Hubble teams to verify and certify all the commanding used in 
Hubble servicing and operations. Afterward, she was the NASA Technology Inventory Manager 
funded by NASA HQ Chief Technologist Office. She led a multi-Center team and documented 
$1.3 Billion dollar of annual technology investments for the Agency. In 2003 Ms. So joined the 
Mission Engineering and Systems Analysis Division, first as the senior Technologist, then the 
Associate Branch Head of the Earth Science Systems Engineering Branch, the Branch Head of the 
Mission Systems Engineering Branch, and as an Associate Division Chief for the Division. She 
graduated with her MA degree in Computer Science from University of Calgary, Canada and her 
BA degree from University of California, Berkeley. She is a member of the American Institute of 
Aeronautics and Astronautics (AIAA) Space Systems Technical Committee, the International 
Council on Systems Engineering (INCOSE), and IEEE. 


Caroline Twomey Lamb is a doctoral candidate at MIT’s Lean Advancement Initiative (LAI). 
She is pursuing her degree through MIT’s Department of Aeronautics and Astronautics. Her 
primary interests focus on enterprise issues within the aerospace industry. Past research and 
experience includes modeling and analyzing turbine quality control procedures and composites 
fabrication and structural testing. Ms. Lamb received her S.B and S.M from MIT in 2003 and 
2005 respectively. She is an active member within the American Institute of Aeronautics and 
Astronautics. 


Dr. Donna H. Rhodes is a Senior Lecturer and Principal Research Scientist in the MIT 



Engineering Systems Division. Previously, Dr. Rhodes held senior management positions in 
several corporations. She is a co-founder of the MIT Systems Engineering Advancement Research 
Initiative (SEAri), directing its research program and advising graduate students. She also leads 
research in enterprise systems engineering for the Lean Advancement Initiative at MIT. She is a 
Past President, Fellow, and Founder of INCOSE, and director of the SEANET doctoral student 
network. She has published numerous papers in the field of systems engineering. Her research 
focuses on architecting and design of complex systems, systems-of-systems, and enterprises. She 
holds a M.S. and Ph.D. in Systems Science from T.J. Watson School of Engineering at 
Binghamton University. 


